Organising digital product teams for success using Team Topologies & Dual Track Agile

I’ve spent the past 3 years as a Digital Program Lead on a large, complex digital modernization program where I’ve learned a lot about organizing and scaling digital product teams and how to adapt the digital operating model as the context changes. The following is a summarized list of how we adjusted the model and some key lessons learned.

For this particular challenge the foundations of the operating model were based on:

Team Topologies - how to organise business and technology teams for fast flow - provides a coherent vocabulary and ways of working together across teams to achieve good software delivery.

Dual Track Agile - how to embed Design Thinking into each stream-aligned product/feature team - dual track ensures customer research led product development is part of each product teams work iteration.

This is how we organised and iterated over the phases 

Proof of Concept (PoC) Phase: Separate Design/Discovery and Stream-aligned Engineering Team

We had a single design-discovery team of product and UX design folks who completed "just enough" customer research to design the core customer experience (Cx) and worked closely with the engineering teams on the domain-driven design (DDD) to define the data model and bounded context (GraphQL APIs) for the PoC.

We had a single stream-aligned engineering team focused on a small end-to-end flow of the core journey to test our assumptions around the architecture, customer experience, and to figure out the next stage team structure, while the Design/Discovery teams continued building out the next set of Cx flows.

Most Valuable Part (MVP) Phase: Merged Design/Discovery & Engineering to Create Stream-aligned Feature Teams Running Dual Track Agile

Each stream-aligned feature team worked across a core domain area with a clear vision and purpose, with dual track ensuring tighter collaboration between Cx design and software design and development. And to ensure they had all skills required to go from idea to working software.

We also implemented the following Team Topology teams:

• 1 x Complicated Subsystem Team: Enterprise data team handled event stream, queue, and data replication to the Mainframe

• 1 x Enablement Team: DevOps team to set up the initial CI/CD tooling and pipelines

• 1 x Enablement Team: Observability team to set up App Insights alerting and monitoring

• 1 x Platform Team: Cloud team for handling all network (Cloudflare) and cloud (Azure) Infrastructure

Continuous Value Delivery Phase: Scaling to 120+ and 12 Teams over 24 Months

• Stream-aligned: Increased from 2 to 6 feature teams as scope increased, we tackled new Cx journeys and domain areas, but also kept team size to below 12

• Enablement Team: We folded DevOps & Observability into a single DevObs team, as tooling matured and stream teams could take on more CI/CD, metrics, alerting, and monitoring

• Complicated Subsystem Team: Enterprise data team needed to increase in size to support 6 stream-aligned teams

• Platform Team: Cloud and network teams remained unchanged in support of the program

Here are some of the most important lessons learned

Team topologies is an engineering-focused framework for aligning teams to business processes and domains. There is not much mention about customer-centricity and design thinking or how designers fit into the model. So the application of Jeff Patton's Dual Track Agile within each stream-aligned team was a really good marriage. It meant that each stream-aligned product team used design thinking to bake customer research-led product development into their ways of working.

Watch out for bottlenecks as you scale stream-aligned teams. We found the enterprise data team (complicated subsystem) came under pressure to service so many feature-product teams. So stream teams took on more of the below-the-line API/data requirements once the subsystem team reached 12 people. We favored this over creating more subsystem teams so that stream teams could own more of the E2E architecture without losing velocity.

Also, watch out for team size, as certain stream teams approached 12+ people, we looked to split the teams into smaller pods, in some instances sharing some full-stack roles like product, design & delivery. This required a bit more coordination for those 3 roles but still better than 20+ person teams across multiple time zones.

Treat the operating model as a product, with team leads & execs as the product team. This meant we were always inspecting and adapting the model across the program to meet the shifting needs of the business, stakeholders, and customers.

Our teams spanned IST, CET, Europe time zones, which made collaboration difficult at critical times. So we split teams into no more than 2 time zones and no less than 4 hours overlap. But only where we were able to ensure all full-stack roles were present.

------

I’d love to hear your thoughts and experience working with either or both Dual Track Agile & Team Topologies?